О чем эта статья
Данная статья представляет собой кейс, в котором демонстрируется вариант настройки конфигурации «1С:Управление торговлей 11» и реализация бизнес-процесса сборки по шагам – с входными и выходными данными, перечнем документов, отвечающих за операции процесса. Важно, что в статье расчет себестоимости производится для каждого собранного комплекта.
Эта статья будет в первую очередь интересна тем, кто занимается внедрением. Она демонстрирует, как хорошее знание конфигурации может помочь обойтись на проекте без существенных изменений кода.
Применимость
Статья написана для редакции УТ 11.1. Если вы используете эту редакцию, отлично — прочтите статью и внедряйте рассмотренный функционал.
Если Вы работаете со старшими версиями УТ 11, то данный функционал является актуальным. Наиболее заметным отличием УТ 11.3/11.4 от редакции 11.0 является интерфейс Такси.
Поэтому, чтобы освоить материал статьи — воспроизведите представленный пример на своей базе УТ 11. Таким образом Вы закрепите материал практикой :)
Расчет себестоимости единиц продукции при сборке товаров
Представим себе ситуацию: предприятие занимается сборкой каких-то сложных устройств (например, сборкой оборудования, либо эксклюзивной продукции). В таком случае нас волнует себестоимость каждой единицы продукции. Рассмотрим данную ситуацию на примере системных блоков.
Итак, наша фирма собирает системные блоки. При этом, у нас нет стандартной комплектации данного оборудования, каждый системник «индивидуален». Здесь то и возникает вопрос – как оценить выгодность каждой конкретной сделки? Только рассчитав себестоимость каждого системника в отдельности! Тем более, что от нее зависят и другие показатели – например, зарплата продавцов, размер премий драгоценных топ-менеджеров и т.д.
Но вот незадача…В УТ 11, как мы знаем из курса, вне зависимости от выбранного способа расчета, себестоимость единицы продукции с одинаковой аналитикой в рамках месяца усредняется. Таким образом, для решения данной задачи, нам нужен некий аналитический разрез.
Давайте посмотрим на структуру регистра «Себестоимость товаров»:
(Нажмите, чтобы увеличить картинку)
Итак, нам доступны «Склад», «Номенклатура» и «Характеристика».
Делаем простой вывод: для расчета точной себестоимости единицы продукции нам необходимо каждый раз заводить новый элемент справочника «Номенклатура» либо «Характеристики номенклатуры». (Либо третий вариант – каждый раз заводим новый склад и бьемся головой об стену, что не рекомендовано).
Это решение грозит нам разрастанием справочника, но без него – никак. Поэтому, выбирая из двух зол меньшее, получаем, что удобней использовать характеристику (так как этот справочник используется не для всех видов номенклатуры!).
Поэтому первое, что мы делаем, – создаем новый «Вид номенклатуры» – “Системные блоки” и включаем возможность использования характеристик.
(Нажмите, чтобы увеличить картинку)
Второе, что нужно настроить для отражения бизнес-процесса продажи системников – это склад, так как именно на складе настраивается вариант контроля остатков.
(Нажмите, чтобы увеличить картинку)
Из четырех вариантов, предлагаемых УТ 11, нам подходит только вариант – “Остатки с учетом графика”, так как только он позволяет отражать заказ клиента без учета фактического наличия остатков товаров на складе. А у нас именно такая ситуация – в тот момент, когда покупатель оставляет заявку на сборку системника, его может и в помине там не быть.
Итак, решение о методе учета принято, предварительные настройки выполнены, можно приступать к описанию бизнес-процесса продажи и сборки системника.
ШАГ 1
Приходит покупатель, говорит, что ему нужен системный блок. Для отражения этого системника в справочнике Номенклатура у нас уже заведена позиция (назовем ее просто – «Системный блок»). Осталось создать новую характеристику для отражения именно нашего системника (наименование строго индивидуально, так что в данном примере назовем его чисто гипотетически):
(Нажмите, чтобы увеличить картинку)
Теперь, менеджеру нужно подобрать комплектующие. При этом нас будет интересовать два момента: остатки на складах и приходная цена комплектующих. Эти данные мы можем получить с помощью обработки «Подбор товаров».
Возникает вопрос – где удобнее это сделать? Логичным ответом было бы – в варианте комплектации… Но тут неожиданно узнаем что обработки подбор в этом справочнике нет (((. Остается один доступный вариант – в документе «Заказ клиента». Менеджер открывает заказ и переходит к обработке «Подбор товаров».
Однако тут также есть одна проблема – цены на товары заполнятся в соответствии с типом цен, установленном в соглашении. В соглашении понятное дело указаны продажные цены, которых в нашей базе для комплектующих может и не быть, нам же нужны закупочные цены. Для их отображения заведем «фиктивное» типовое соглашение с указанным видом цен – «Закупочная», которое будем использовать исключительно для подбора.
Менеджер наконец может подобрать комплектующие:
(Нажмите, чтобы увеличить картинку)
В итоге – у него есть состав и ориентировочная сумма закупки комплектующих.
После этого менеджер создает вариант комплектации для характеристики номенклатуры и заполняет его подобранными комплектующими.
ШАГ 2
Самое время зарегистрировать заказ клиента. В ТЧ добавляем системный блок и созданную номенклатуру, а цену рассчитываем в зависимости от суммы закупочных цен комплектующих (например, полученную в подборе сумму умножаем на ориентировочный процент наценки). Проводим документ в статусе «Не согласован». Документ в этом статусе не формирует движений по регистрам взаиморасчетов и резервов. После чего можем распечатать для клиента заказ, чтобы он про него не забыл :).
(Нажмите, чтобы увеличить картинку)
ШАГ 3
Проводим дли-и-ительные переговоры с заказчиком, после чего меняем статус на «Согласован» – ждем от него предоплату. Документ в этом статусе делает движения по регистрам взаиморасчетов, но резерв не формирует.
ШАГ 4
После того, как предоплата пришла, устанавливаем статус “К обеспечению”. При установке статуса, необходимо заполнить (вручную либо автоматически) реквизит “Дата отгрузки”. Дата отгрузки важна, так как от ее значения зависит положение заказа в графике отгрузке товаров, а также она используется при определении даты, к которой необходимо собрать системник.
ШАГ 5
После этого можно преступать к сборке системника. Сначала сформируем резерв на необходимые комплектующие. Для этого нам понадобится документ «Заказ на сборку» в статусе «К обеспечению». Сборщик получает документы с таким статусом. При этом, возникают ситуации, когда сборщика не устраивает комплектация системника (менеджер ни черта не понимает и сформировал нереальный вариант комплектации). В таком случае он корректирует заказ на сборку.
ШАГ 6
После того как вариант комплектации полностью устраивает сборщика и все комплектующие на месте, сборщик может приступить к сборке. Однако в статусе «К обеспечению» это невозможно:
(Нажмите, чтобы увеличить картинку)
Поэтому необходимо воспользоваться советом 1С и перевести документ в статус «К выполнению».
ШАГ 7
Сборщик создает и проводит документ «Сборка (разборка) товаров» в статусе «К сборке» при этом происходит контроль остатков комплектующих на складе. Убедившись, что все комплектующие есть, сборщик может приступить к сборке системника; для этого он изменяет статус документа сборки на «В работе» в результате чего происходит фактическое списание комплектующих со склада.
(Нажмите, чтобы увеличить картинку)
ШАГ 8
И вот наконец наступил тот торжественный момент, когда сборщик собрал наш системный блок. Он изменяет статус документа «Сборка» на «Собрано». В результате чего системный блок появляется в остатках.
ШАГ 9
Теперь менеджер может установить статус «Заказа клиента» – «К отгрузке» и смело отгружать системный блок со склада.
ШАГ 10
В результате в конце месяца мы получаем себестоимость каждого конкретного системника!! :)
Возможно такая схема покажется кому-то слишком многоступенчатой и к тому же с обилием «костылей»… На практике в моем конкретном проекте пришлось дорабатывать конфу, чтобы работа пользователей была удобней… но сам принцип формирования документов был использован именно такой.
Ну и как принято в нашем с вами курсе, для тех, кто дочитал до конца предназначен бонус– схематичное представление рассмотренного бизнес-процесса :).
(Нажмите, чтобы увеличить картинку)
(Нажмите, чтобы увеличить картинку)
Другие статьи по «1С:Управление Торговлей 11»: